The invention relates generally to database and database management system operations. More specifically, the invention relates to moving a hierarchical database to a quiesce point without causing applications attempting to access the database during the quiesce operation to fail.
Referring to FIG. 1, illustrative computational system 100 comprises database 105 and a plurality of database management systems (DBMS) 110 and 115. Each DBMS is shown as providing an execution environment for a number of different applications (A1→A3 and AX→AZ). In general, database 105 may be used (i.e., accesses and/or updated) by any number of applications, each of which may execute within a different DBMS. Each DBMS may reside on, and execute from, a different physical computer system, each of which may be physically remote from one another.
During normal database operations, it is often useful or necessary to quiesce a database. For example, a utility application (e.g., application A1 in DBMS 110) may want to start or stop log keeping operations or initiate a backup operation against database 105. One of ordinary skill in the art will recognize that these, and similar operations, require forcing database 105 to a quiesce point. As used herein, a “quiesce point” is a point-in-time when there are no incomplete transactions in process against a database and when all database information has been “hardened” (i.e., committed to permanent storage). Accordingly, to “quiesce a database” means to force the database to a quiesce point.
Referring to FIG. 2, prior art quiesce operation 200 shows utility application 205 (e.g., application AX) quiescing database 105 through IMS DBMS 210. Quiesce operation 200 begins when utility 205 issues IMS STOP command 215 to DBMS 210 targeting database 105. In response, DBMS 210 immediately begins to abnormally terminate all access requests issued against database 105 from other applications, 220. As used herein, “to abnormally terminate an access operation” means the request is caused to fail. (In an IMS environment, an abnormal termination is effected by an ABEND action.) As a consequence, all applications issuing such requests are unable to perform the requested task. If database 105 represents a bank's account database for example, and a user/customer attempts to access their account information in database 105 via an ATM after DBMS 210 receives utility 205's STOP command 215, the request will simply fail. As a consequence, the user/customer must either come back at a later time and try again or enter the bank to perform their desired task. In either situation, the bank has likely lost business.
Once new access operations to database 105 are stopped, DBMS 210 waits for all in-flight transactions against database 105 to complete (225) and then closes (230) and deallocates (235) database 105. As part of deallocation operation 235, database 105 has any working memory resident data hardened or written to permanent storage (e.g., one or more direct access storage devices). In many environments, database management systems do not provide a positive acknowledgement that a commanded task has completed. It is common, therefore, for requesting utility 205 to periodically query DBMS 210 to determine when prior issued STOP command 215 has completed (240). After deallocation process 235 has completed, and in response to such a query, DONE message 245 may be transmitted by DBMS 210 to utility 205. Requesting utility 205 may now perform (or have performed) the task for which STOP command 215 was issued (250). For example, utility 205 may start or stop logging operations against database 105. Once task 250 is complete, utility 205 may issue IMS START command 255 to DBMS 210 targeting database 105. In response, DBMS 210 allocates (260) and opens (265) database 105. Following completion of OPEN command 265, DBMS 210 permits access to database 105 (270). As before, utility 205 may periodically query DBMS 210 to determine when START operation 255 has completed (275), DBMS 210 issuing DONE message 280 when appropriate.
As illustrated, prior art quiesce technique 200 causes periods of database outage—times during which applications attempting to access the database being quiesced fail. For a business, each such failure can lead to the direct loss of business. Thus, it would be beneficial to provide a means to quiesce a database without causing applications attempting to access the database to fail.